home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re ClearPartStorage < prev    next >
Encoding:
Internet Message Format  |  1996-07-24  |  2.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ClearPartStorage
  2. Sent:        7/24/96 9:16 AM
  3. Received:    7/24/96 9:31 AM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. And now my answer,
  9.  
  10.  
  11. You will see much improvement in ODF 2. I now maintained a diry flag in 
  12. the content object so I will not externalize anything when externalize is 
  13. called but your data haven't changed. Also I am not anymore emptying the 
  14. part storage automatically like I was doing. I let you do it if you want 
  15. (there are new utilities method to either empty a value or clear up the 
  16. end of a value). Also, ODF 2 has now support for multiple kinds and 
  17. implements the preferred kind recipe.
  18.  
  19.  
  20. >As I think Arni noted, the ODF practice of removing the part's prefered
  21. >kind and then letting the part externalize is causing severe document
  22. >bloat. Bento is not reclaiming the space very well.
  23. >
  24. >My own results... With 6 ODF based Rapid-I Button parts (with picture
  25. >labels and script actions) embedded in ODF Container, I can account for
  26. >about 200K of needed storage. After making a single change to the 
  27. >document,
  28. >it bloats out to > 400K. Doing a "Save a Copy..." reduces the document 
  29. >size
  30. >down to just over 200K.
  31. >
  32. >I think what's happening here is that if a silly little change is made to
  33. >an inconsequential little part, each part has to externalize itself. Thus,
  34. >each ODF part clobbers its old contents property, and Bento lets the
  35. >document size double.
  36. >
  37. >A good solution might be an "fPartChanged" flag in FW_CPart, set when
  38. >FW_CPart::Changed is called. Right now, that method just flags the 
  39. >document
  40. >as dirty. If a part is unchanged, then it has no work to do at
  41. >externalization time.
  42. >
  43. >Now, for those of us caching data in frames, it would also be useful to
  44. >have a changed flag just for each FW_CFrame, so that we don't have to
  45. >externalize cache data for a frame that hasn't changed.
  46. >
  47. >This whole solution would also cut down on externalization time of ODF
  48. >parts. With lots of parts in a document, the time savings could be
  49. >significant.
  50. >
  51. >So, does this make any sense?
  52. >
  53. >Brad
  54. >
  55. ><mailto: "Brad Hutchings" brad@hutchings-software.com>
  56. ><http://www.hutchings-software.com>
  57. >
  58. >Got OpenDoc? Got Cyberdog? Then beta-test Rapid-I Button! Email me for 
  59. >more
  60. >information...
  61.  
  62.  
  63. ........................................................................
  64.  Henri Lamiraux                                      lamiraux@apple.com
  65.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  66. ........................................................................
  67.  
  68.  
  69.